Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create swift.yml #1

Open
wants to merge 446 commits into
base: move-docs-for-sealed-sender-v2-to-docstring
Choose a base branch
from

Conversation

Playgirlkaybraz11
Copy link

test/serialization.test.tshttps://github.com/signalapp/pull/476#issue-1285445075

A SenderCertificate object stores both the serialized bytes and the
deserialized fields that make up the certificate, which means that
converting from an in-memory protobuf representation requires
serializing back to bytes. Avoid that extra step by delaying the
deserialization of the SenderCertificate protobuf.
The prost crate documents that encoding can only fail if the buffer
being encoded to is too small, which can never happen when encoding to
a Vec.
Originally InvalidCiphertext meant something structurally wrong, while
InvalidMessage meant it wasn't decryptable. But distinguishing those
isn't really important except for debugging purposes, so using a
string description is sufficient.
Making this error actionable means including the distribution ID, and
even without exposing that to apps it'll show up better in logs.
...not an illegal state. Also, put the distribution ID in here too,
for good measure.
This is returned as a SessionNotFound error so that the recipient's
address can be included, but it's important to clarify that it's the
identity key that's missing.
The main purpose of this is to distinguish new-session PreKey message
failures from established-session Whisper message failures.

In some cases this meant *not* using InvalidMessage, because the error
wasn't for a particular CiphertextMessage.
- Provide a fallback for generating random data that doesn't use
  Security.framework.
- Fix package unsafe linker settings for ld.gold compatibility.
- Don't depend on the UUID_NULL constant.
Pros:

- Linux executors are cheaper on GitHub's CI, when running in the
  private repository.

- Checks that the Swift package can still be built and tested on
  Linux, even though that's not a primary goal.

Cons:

- Removed the code coverage report. It's possible to do this on Linux
  as well, but we haven't been using this as a primary tool, and it's
  still possible to check locally (particularly by running in Xcode).
  The coverage of the Rust tests is more interesting anyway, and we
  haven't had an automated report for *that*.

Neutral:

- Moved the SwiftLint run to the "Swift CocoaPod" job, since SwiftLint
  isn't installed on GitHub's Linux images by default. Even though
  "Swift CocoaPod" is the longest job at the moment and we may want to
  shorten it, the SwiftLint action is quick anyway.
All our bridges translate panics to platform-specific errors anyway;
there's no advantage in using a dedicated error for things that should
*really* never happen.
The former was used for errors in the protobuf format itself, while
the latter was used when the decoded protobuf failed some higher-level
precondition. But apps can't really distinguish those cases, and
neither one "should" happen in a reliable system, so this is just
defending against rare or malicious inputs.

This commit mechanically turns every prost::DecodeError into
InvalidProtobufEncoding, but the next commit will make more of a
distinction of these errors.
Code using cpufeatures to check for hardware support for cryptographic
operations will now be able to do so on 64-bit Android as well.
This was done by `cargo update`, followed by reverting to earlier
versions of specific crates that have trouble on our current pinned
nightly.
No updates needed for the run-time dependencies.
Some were overzealous, others were missing. Some are still not really
appropriate; see further commits.
Anything that stays within the crate gets a dedicated error type, or
no error at all if the operation cannot actually fail. The "defensive"
signatures remain for public operations.

Apart from making 'Result' more meaningful, this also keeps from
propagating low-level errors out that really indicate a corrupt
session.
Similar to the previous commit, this makes crate-internal operations
use a dedicated error type, or not produce an error at all, in order
to make sure that errors for invalid sessions always have the
distribution ID attached.
We use this when the record for a given distribution ID is missing the
state for a particular chain ID.
In Java these are subclasses of IllegalStateException, a
RuntimeException, so that every session operation isn't annotated as
throwing InvalidSessionException. Swift and TypeScript don't have
typed errors, so they're just additional specific cases that can be
caught.
This helper task was supposed to only execute when publishing the
client or server artifacts, but at the point where that was checked
the task graph *hasn't been built yet*. Instead, add the task to the
task graph unconditionally, but disable it by default, and have its
dependents enable it only when publishing.
Previously the project would error out during the configuration stage,
since the Android Gradle plugin requires JDK 11 to even load. Now it
throws an error if you try to build a top-level task or a task in the
Android subproject, but allows you to build, e.g. 'client:test' with
no problems.
- org.whispersystems.libsignal -> org.signal.libsignal.protocol
- org.whispersystems.libsignal.protocol ->
    org.signal.libsignal.protocol.messages
- org.whispersystems.libsignal.util.AndroidSignalProtocolLogger ->
    org.signal.libsignal.logging.AndroidSignalProtocolLogger
- org.signal.zkgroup -> org.signal.libsignal.zkgroup
- org.signal.devicetransfer -> org.signal.libsignal.devicetransfer
  (test only)
- org.signal.client.internal -> org.signal.libsignal.internal
- Java: org.whispersystems:signal-client-java ->
    org.signal:libsignal-client
- Java: org.whispersystems:signal-client-android ->
    org.signal:libsignal-android
- Java: org.whispersystems:libsignal-server ->
    org.signal:libsignal-server
- Swift: SignalClient -> LibSignalClient
- NPM: @signalapp/signal-client -> @signalapp/libsignal-client
- Repository: github.com/signalapp/libsignal-client ->
    github.com/signalapp/libsignal
jrose-signal and others added 29 commits June 9, 2023 11:49
In a future release ProtocolAddresses will *only* support ServiceIds,
so these APIs are designed to be the nullable version of the signature
they'll eventually have. Since ProtocolAddresses are created by the
client app in nearly all cases, they should be able to ignore the null
case if they only use ServiceIds in their input.
Signal Desktop only supports Ubuntu 20.04 and newer, so we no longer
need to build against Ubuntu 16.04 to ensure compatibility. And
bullseye-slim is a smaller base image than the Ubuntu images, so if we
don't specifically need an Ubuntu package this should be an easy
improvement.
This does mean that the 'bytes' field in a UidStruct isn't as useful
anymore, because it can't distinguish different kinds of ServiceIds
without extra work. Unfortunately, it was serialized inside a
client-stored AuthCredential, so we can't just change it or take it
out. Fortunately, nothing actually reads this field anyway except when
decrypting, so it's okay to change how decryption works and ignore the
'bytes' field going forward.
Will be used more heavily in later commits.
Eventually all of zkgroup will use ServiceId, but this part will
actually behave differently.
Some of these APIs have to match up with UuidCiphertexts, and so we
convert them all for consistency.
The former is what we want going forward; the latter is equivalent to
the old format for compatibility with previous client builds.
@Playgirlkaybraz11 Playgirlkaybraz11 changed the base branch from main to move-docs-for-sealed-sender-v2-to-docstring June 14, 2024 23:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.